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This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 
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Scope 



The scope for the present document is to specify normative rules for how to use the Gq', Rq and la protocols 
(TS 183 017 [4], ES 283 026 [3] and ES 283 018 [7]) as of TISPAN release 1. These rules apply to the interface 
between: 

• P-CSCF and SPDF using Gq'; 

• IBCF and SPDF using Gq'; 

• SPDF and (C- and I-) BGF using la; 

• SPDF and A-RACF using Rq. 

In addition, to illustrate the usage of these rules, the present document contains informative signalling flows between 
the above-listed entities. 

Non IMS AF entities are out of scope of the present document. Thus, the rules for using the Gq', Rq and la protocols 
and the signalling flows provided do NOT cover possible signalling scenarios for non-IMS applications. They describe 
however basic principles for how parameters travel via these protocols for IMS, which should be considered when using 
these protocols for non-IMS AF entities. In case of any discrepancy between the end-to-end IMS signalling flows in the 
present document and the ETSI TISPAN IMS specifications (TS 182 006 [5] and ES 283 003 [6]), the ETSI TISPAN 
IMS specification shall take precedence. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time AppHcations". 
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[2] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+);Universal Mobile 

Telecommunications System (UMTS); Policy control over Go interface". 

[3] ETSI ES 283 026: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN);Resource and Admission Control; Protocol for QoS reservation 
information exchange between the Service Policy Decision Function (SPDF) and the Access- 
Resource and Admission Control Function (A-RACF) in the Resource and Protocol specification". 

[4] ETSI TS 183 017: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF);Protocol specification ". 

[5] ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description 
(3GPP TS 23.228 v7.2.0, modified)". 

[6] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7], modified]". 

[7] ETSI ES 283 018: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile for controlling 
Border Gateway Functions (BGF) in the Resource and Admission Control Subsystem (RACS); 
Protocol specification". 

[8] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A-RACF Access - Resource Admission Control Function 

AAA AA-Answer 

AAR AA-Request 

AF Application Function 

AVP Attribute Value Pair 

C/I-BGF Core/Interconnection Border Gateway Function 

CLE Connectivity session Location and repository Function 

IBCF Interconnection Border Control Function 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

MG Media Gateway 

MGC Media Gateway Controller 

NAPT Network Address and Port Translation 

NAPT-PT Network Address and Port Translation - Protocol Translation 

PCMU Pulse Code Modulation Mu-law 

P-CSCF Proxy - Call Session Control Function 

RACS Resource and Admission Control Subsystem 

RTP Real Time Protocol 
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RTCP 

SIP 

SPDF 

SDP 

UE 

UL 

DL 

UDP 



Real Time Control Protocol 

Session Initiation Protocol 

Service-based Policy Decision Function 

Session Description Protocol 

User Equipment 

Up Link 

Down Link 

User Datagram Protocol 



Example call flow (informative) 



A-RACF 



C-BGF/I-BGF 



SPDF 



P-CSCF/IBCF 



SDP offer/ 
answer received 



I 



Define 
connection info. 



-Diameter AAR- 



SPDF policy 



-H.248 ADD- 



Create 
terminations 



H.248 ADD reply- 



Extract 
termination 
addresses 



-Diameter AAR- 



Resource and 

policy based 

admission control 



-Diameter AAA- 



Diameter AAA- 



Modify SDP 

offer/answer 



Figure 4.1 : RACS, BGF and P-CSCF/IBCF interactions 

Figure 4. 1 illustrates the basic interactions involved when requesting a resource reservation from RACS for an IMS call. 
It should be noted that the SPDF may interrogate I/C-BGF and A-RACF in any order. Hence, interacting with the 
I/C-BGF before the A-RACF as shown in figure 4. 1 is not mandated and the extraction of termination addresses done 
by the SPDF does not rely on any information coming from I/C-BGF. Instead this extraction is made from the Diameter 
AAR only. The interactions illustrated in figure 4. 1 are repeated twice for each call setup and each SPDF instance along 
the path of the attempted call as described in the following clauses. 
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5 RAGS related procedures (normative) 

5.1 Procedures at P-CSCF/IBCF 

5.1 .1 Resource and admission control 

This clause describes the rules used by the P-CSCF/IBCF to derive the bandwidth to request from RACS. 

In case being present, the b= attribute will correspond to the bandwidth required by the most bandwidth demanding 
codec in the list. Hence, the Max-Requested-Bandwidth-UL and -DL shall be set to the value given by the b= attribute 
if present. 

In case the b= attribute is not present the P-CSCF/IBCF shall set these AVPs according to one of the following rules: 

• Set the AVPs to the value locally associated to the codec received in the m= line when only one codec is listed 
in the m= line or the highest bandwidth required by the codecs listed in the SDP offer (when multiple codecs 
are proposed for this media component). 

• Set the AVPs to the value locally associated to the codec received in the m= line when only one codec is listed 
in the m= line or the lowest bandwidth required by the codecs listed in the SDP offer (when multiple codecs 
are proposed for this media component). In this case the Max-Requested-Bandwidth-UL and -DL AVPs may 
not reflect the actual bandwidth value that will be negotiated for the session. 

• Omit the AVPs and let RACS determine a default bandwidth based on the combination of Reservation-Class 
and Media-Type AVPs. 

The above-given rules are in line with the description given in annex B (table B.l)ofTS 183017 (Gq') [4] for how to 
populate the Max-Requested-Bandwidth-UL and -DL AVPs. These rules provide however more details on how to 
populate these AVPs referred to from TS 183 017 [4] in annex B (table B.l). 

It should be noted that the above-given rules imply that the Max-Requested-Bandwidth-UL and -DL AVPs may be 
modified during the SDP negotiation (i.e. when the codec to be used is finally agreed between the endpoints). 

5.1 .2 NAPT/NAPT-PT at the P-CSCF/IBCF 

Details on NAPT/NAPT-PT operations at the P-CSCF are given in TS 124 229 [8]. 

The IBCF supports controlled NAPT/NAPT-PT but does not support hosted NAPT/NAPT-PT traversal. That is, the 
IBCF is capable of replacing addresses and ports in the SDP as ephemeral terminations are created following the rules 
given in clauses 5.2.1.3 and 5.2.1.4, but the IBCF cannot handle address latching as used for hosted NAPT/NAPT-PT 
traversal. The P-CSCF is capable of both hosted NAPT/NAPT-PT traversal and controlled NAPT/NAPT-PT. 

5.2 Procedures at SPDF 

For resource and admission control purposes the SPDF will determine on local policy as specified in TS 183 017 [4] 
whether a C-BGF and/or an A-RACF need to be involved in the AF session. 

5.2.1 Reservation with BGF involved 

The SPDF procedures related to the Gq' interface involved in supporting NAPT/NAPT-PT services provided by the 

BGF and in supporting resource and admission control services provided by the A-RACF are described in 

TS 183 017 [4]. Based on these procedures this clause describes the operations of the SPDF involved in co-ordinating 

requests for these services made over Gq' with the required signalling over the la and Rq interfaces. The translation of 

values not specific to address translation received over Gq' to values used for request made over la is described in 

clause 5.2.1.1, operations involved in co-ordinating requests for NAPT/NAPT-PT services are described in 

clause 5.2.1.2, while the operations involved in co-ordinating resource and policy based admission control services are 

described in clause 5.2.1.3. 
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5.2.1 .1 Resource reservation at the BGF 



Upon reception of an initial reservation (SDP offer) the SPDF will extract from the information received with the AAR 
the important information in order to reserve resources at the transport layer, different AVPs will be received included 
in the AAR, only some of them will be retransmitted over the la interface. The aim of this clause is to provide the 
transcription for those AVPs: 

• The Transport class AVP may be used for pointing to a class of transport services to be applied as detailed in 
TS 183 017 [4], in that way it may indicate the DSCP marking and the command syntax over the la interface 
may be ds/dscp, this information may be sent through the local control descriptor. 

• The value of the Reservation priority AVP may be sent over the la interface as the priority of the context. 

The following table summarizes the population rules for setting context and termination properties, based on received 
DIAMETER AVPs and local configuration data. 
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Table 5.2.1.1.1 



Context 
parameters 



Descriptor 



Descriptor 



Descriptor 



Properties 



Population rules 



Context ID 



Always set by the BGF 



Priority 
Indicator 



Set from the Reservation-Priority AVP 



Emergency 
Indicator 



Set from the Service Class AVP 



Term ID 



See ES 283 018 [7] 



IVIedia 



Stream 



Local 
Control 



mode 



ds/dscp 



gm/saf 



gm/spf 



gm/sam 



gm/spr 



gm/rsb 



gm/esas 



gm/lsa 



gm/esps 



gm/Isp 



tman/pdr 



tman/mbs 



tman/dvt 



tman/sdr 



tman/pol 



Set from Flow-Status in Media-Component-Description 
and/or Flow-Status in Media-Component. Media-Sub- 
Component 



Set from Transport-Class in Media-Component- 
Description. 



Depends on the Service-Class AVP and BGF profile 
information. 



Depends on the Service-Class AVP and BGF profile 
information. 



If gm/saf is set to ON, the gm/sam property is set from 
the Flow-Description in Media-Component. Media-Sub- 
Component 



If gm/spf is set to ON, the gm/spr property is set from 
the Flow-Description in Media-Component. Media-Sub- 
Component 



Depends on the value of the Media-Type AVP and BGF 
profile information. 



Depends on the Service-Class AVP and whether 
NAP-PT is activated. 



If gm/esas is set to ON, gm/lsa is set from the address 
(c= line) contained in the remote descriptor of the 
opposite termination. 



Depends on the Service-Class AVP and whether 
NAP-PT is activated. 



If gm/esps is set to ON, gm/Isp is set from the port 
(m= line) contained in the remote descriptor of the 
opposite termination. 



If the Transport-Class corresponds to constant bit rate 
traffic, the tman/pdr property shall be equivalent to the 
b= line of the local descriptor or absent. 
If the Transport-Class corresponds to variable bit rate 
traffic, the tman/pdr property shall be equivalent to the 
b= line of the local descriptor. 



From Reservation-Class AVP 



From Reservation-Class AVP 



If the Transport-Class corresponds to constant bit rate 

traffic, this property shall be omitted or identical to 

tman/pdr. 

If the Transport-Class corresponds to variable bit rate 

traffic this property shall be derived from tman/pdr using 

rules specific to the transport class. 



Set from the Transport-Class AVP. 



Local 



c= 

If NAPT-PT is activated, the address shall be assigned 

by the BGF. Otherwise the address is set from the 

contents of the remote descriptor of the opposite 

termination. 

See ES 283 01 8 [7] for the setting of other fields of the 

c= line. 
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Context 
parameters 


Descriptor 


Descriptor 


Descriptor 


Properties 


Population rules 












m= 

If NAPT-PT is activated, the port shall be assigned by 
the BGF. Otherwise the port is set from the contents of 
the remote descriptor of the opposite termination. 
See ES 283 018 [7] for the setting of other fields of the 
m= line. 


b= 

Shall be set from the Max-Requested-Bandwidth-UL or 

Max-Requested-Bandwidth-DL depending on the 

termination (upstream or downstream). 

(see note) 


Remote 




c= 

The address is set from the Flow-Description in 

Media-Component. Media-Sub-Component. 

See ES 283 018 [7] for the setting of other fields of the 

c= line. 


m= 

The port is set from the Flow-Description in 

Media-Component. Media-Sub-Component. 

See ES 283 018 [7] for the setting of other fields of the 

m= line. 


b= 

Shall be set from the Max-Requested-Bandwidth-UL or 

Max-Requested-Bandwidth-DL depending on the 

termination (upstream or downstream). 

(see note) 


NOTE: If gm/rsb is set to ON, the value of the AVPs associated to the RTGP flow shall be added. 



5.2.1.2 



Specific Actions at the BGF 



See la-to-Gq' mapping guidelines in ES 283 018 [7], annex E. 

NOTE: The present document has TISPAN Release 1 in scope, whereas the referred ES 283 018 [7] provides the 
H.248 la profile version 2 for TISPAN Release 2. This is considered not to be an issue because the 
present document is not yet providing signalling flow examples with the Specific Action AVPs. 



5.2.1.3 



Initial reservation for an session (SDP offer) 



Upon reception of an initial AAR with connection information, the SPDF shall extract the connection information from 
the Media-Component-Description AVP(s). 

Each Media-Component-Descriptor AVP received (one per m= line or media stream) contains one or more 
Media-Sub-Component AVP(s) carrying a set of Flow-Descriptor AVP(s) that describe a unidirectional IP flow 
associated with the media stream. 

The SPDF shall from the set of Flow-Descriptor AVP(s) identify the direction of the corresponding IP flows i.e. uplink 
or downlink. The direction of each IP flow is given by the value of the direction attribute of the corresponding 
Flow-description AVP (i.e. "in" for uplink IP flows, and "out" for downlink IP flows). For each potential requesting 
application that requires the services of a BGF, the SPDF shall hold a local mapping table that enables SPDF to ensure, 
that both ephemeral terminations created for the session in the BGF are configured with connection information that 
matches appropriately the IP flow direction with the network interface connecting the ephemeral termination. 

In the P-CSCF case, an uplink IP flow originates from the UE served by the P-CSCF, and a downlink IP flow is 
directed towards the UE served by the P-CSCF. 

In the IBCF case, an uplink IP flow is directed from the local core network towards the peer core network, and a 
downlink IP flow is directed from the peer core network towards the local core network. 
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The Binding-Input-List AVP shall be populated with an even number of V4-Transport- Address AVP or 
V6-Transport- Address list elements. The first list element in each pair of list elements applies to the access side and the 
second element applies to the core side. In case one of the V4-Transport- Address AVP or V6-Transport- Address AVP 
in such pair is unknown, an even number of list elements shall be still provided with the unknown 
V4-Transport- Address AVP or V6-Transport- Address AVP wild-carded. 

The above-given rules apply to the P-CSCF but are also valid for the IBCF provided that "access side" is replaced by 
"local core side" and "core side" by "peer core side". It shall be one pair of V4-Transport- Address AVP or 
V6-Transport- Address list elements in the Binding-Input-List AVP for each single Media-Component-Description AVP 
in an AAR. The list of such pau's shall be given in the same order as the list of Media-Component-Description AVPs. 
This provides an explicit coupling between each Media-Component-Description AVP, each pair of list elements in the 
Binding-Input-List AVP, and each pair of terminations in the BGF. 

The following description for how to create ephemeral terminations applies to the P-CSCF but is also valid for the IBCF 
provided that "access network" is replaced by "local core network" and "core network" by "peer core network". 

After selection of the BGF to be contacted for the session, the SPDF requests initial configuration of the BGF to create 
a context with two ephemeral terminations: 

• ephemeral termination TA connecting the access network to the BGF; and 

• ephemeral termination TC connecting the core network to the BGF. 



Access UL 



Local Core 



"T^r 



Gate 



T 



Gate 



H.248 Context 



Local Core 



Peer Core 



Figure 5.2.1.3.1 : BGF connection and flow model representation 

For connection information corresponding to a downlink IP flow, the SPDF shall: 

• on termination TA, 

define one media stream per Media-Component-Description AVP occurrence (see note 1), 

■ for each media strea, 

set the remote Descriptor to the corresponding destination IP and port address of the 
Flow-Description AVP marked with "out" direction and contained in the 
Media-Sub-Component AVP for which the Flow-Usage AVP is either absent or set to 
"no_information". 

• on termination TC, 

define one media stream per Media-Component-Description AVP occurrence (see note 1), 

■ for each media stream, 

if destination address NAPT(-PT) is activated for DL IP flows, request the BGF to select an 
IP and port address in the local Descriptor and store the selected value; 

otherwise i.e. if destination address NAPT(-PT) is not activated for DL IP flows, set the local 
Descriptor to the value assigned to the remote Descriptor of termination TA; 

optionally, configure the local control Descriptor with the gm/lsa and gm/lsp set to the value 
assigned to the remote Descriptor of termination TA (see note 2). 
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For connection information corresponding to an uplink IP flow, the SPDF shall: 

• on termination TC, 

define one media stream per Media-Component-Description AVP occurrence (see note 1), 

■ for each media stream, 

set the remote Descriptor to the corresponding destination IP and port address of the 
Flow-Description AVP marked with "in" direction and contained in the Media-Sub- 
Component AVP for which the Flow-Usage AVP is either absent or set to "no_information". 

• on termination TA, 

define one media stream per Media-Component-Description AVP occurrence (see note 1), 

■ for each media stream, 

if destination address NAPT(-PT) is activated for UL IP flows, request the BGF to select an 
IP and port address in the local Descriptor and store the selected value; 

otherwise i.e. if destination address NAPT(-PT) is not activated for UL IP flows, set the local 
Descriptor to the value assigned to the remote Descriptor of termination TC; 

Optionally, configure the local control Descriptor with the gm/lsa and gm/lsp properties set to 
the value assigned to the Remote Descriptor of termination TC (see note 3). 

NOTE 1: The SPDF can also specify additional media stream for RTCP this is described in ES 283 018 [7]. 

NOTE 2: This ensures that UL IP flows will be sent towards the core network using a source IP and port address 
identical to the address used by the UE for sending packets, assuming that the UE sends and receives 
packets using the same address and port. 

NOTE 3: This ensures that DL IP flows will be sent towards the access network using a source IP and port address 
identical to the address used to by the peer for sending packets, assuming that the peer sends and receives 
packets using the same address and port. 

If destination address NAPT(-PT) is activated for UL and/or DL IP flows, the SPDF shall return in the AAA message 
the list of IP and port address(es) selected by the BGF as local Descriptors in the Binding-Output-List AVP for each 
media stream in the same order as the corresponding Binding-Input-List AVP of the AAR message. 

5.2.1 .4 Connection information received from the opposite direction (SDP answer) 

Upon reception of a subsequent AAR with connection information, the SPDF shall extract the connection information 
from the Media-Component-Description AVP(s). These operations are performed as described in the previous clause. 

The rules for how to populate the Binding-Input-List AVP and its relation to Media-Component-Description AVPs 
given in clause 5.2.1.3 apply also to this clause. 

The following description for how to create ephemeral terminations applies to the P-CSCF but is also valid for the IBCF 
provided that "access network" is replaced by "local core network" and "core network" by "peer core network". 

After selection of the BGF to be contacted for the session, the SPDF requests subsequent configuration of the context 
created within the BGF. 

For connection information corresponding to a downlink IP flow, SPDF shall: 

• modify termination TA, 

for each media stream, 

■ set the remote Descriptor to the corresponding destination IP and port address of the 
Flow-Description AVP marked with "out" direction and contained in the Media-Sub-Component 
AVP for which the Flow-Usage AVP is either absent or set to "no_information". 
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• modify termination TC, 

for each media stream, 

■ if destination address NAPT(-PT) is activated for DL IP flows, request the BGF to select an IP and 
port address in the local Descriptor and store the selected value; 

■ otherwise i.e. if destination address NAPT(-PT) is not activated for DL IP flows, set the local 
Descriptor to the value assigned to the remote Descriptor of termination TA; 

■ Optionally, configure the local control Descriptor with the gm/lsa and gm/lsp properties set to the 
value assigned to the Remote Descriptor of termination TA (see note 2). 

For connection information corresponding to an uplink IP flow, the SPDF shall: 

• modify termination TC, 

for each media stream, 

■ set the remote Descriptor to the corresponding destination IP and port address of the Flow- 
Description AVP marked with "in" direction and contained in the Media-Sub-Component AVP for 
which the Flow-Usage AVP is either absent or set to "no_information". 

• modify termination TA, 

for each media stream, 

■ if destination address NAPT(-PT) is activated for UL IP flows, request the BGF to select an IP and 
port address in the local Descriptor and store the selected value; 

■ otherwise i.e. if destination address NAPT(-PT) is not activated for UL IP flows, set the local 
Descriptor to the value assigned to the remote Descriptor of termination TC; 

■ Optionally, configure the local control Descriptor with the gm/lsa and gm/lsp set to the value 
assigned to the remote Descriptor of termination TC (see note 1). 

NOTE 1: This ensures that DL IP flows will be sent towards the access network using a source IP and port address 
identical to the address used to by the peer for sending packets, assuming that the peer sends and receives 
packets using the same address and port. 

NOTE 2: This ensures that UL IP flows will be sent towards the core network using a source IP and port address 
identical to the address used by the UE for sending packets, assuming that the UE sends and receives 
packets using the same address and port. 

If destination address NAPT(-PT) is activated for UL and/or DL IP flows, the SPDF shall return in the AAA message 
the list of IP and port address(es) selected by the BGF as local Descriptors in the Binding-Output-List AVP for each 
media stream in the same order as the corresponding Binding-Input-List AVP of the AAR message. 

5.2.1 .5 Connection information (SDP answer) received corresponding to multiple 

early dialogues 

The SPDF may receive more than one AAR with SDP answer connection info in case the AF identifies that multiple 
early dialogues are being created. These AAR will be marked with a SIP-Forking-Indication AVP set to value 
SEVERAL_DIALOGUES. The SPDF shall request resources from the BGF as if this was an AAR (SDP answer) 
without Forking-Indication but shall be prepared to restore QoS requirements for one of the early dialogues. The final 
dialogue is identified when an AAR (SDP answer) is received without the SIP-Forking-Indication AVP. 
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5.2.2 Reservation involving botin A-RACF and BGF 

The signalling flow when both the A-RACF and BGF are involved is a combination of the procedures for accessing the 
BGF specified in clauses 5.2.1 and the procedures for accessing the A-RACF specified in ES 283 026 [3]. 

The sequence used by the SPDF to access A-RACF and BGF is a local decision in the SPDF, e.g. the SPDF is able to 
decide whether to access the A-RACF and then the BGF, or vice versa, or both in parallel. This is valid for request, 
modification and release. 



6 Example signalling flows (informative) 

The examples of stage 3 signalling flows for TISPAN NGN release 1 provided by the present document cover 
signalling between P-CSCF and SPDF using Gq', IBCF and SPDF using Gq', SPDF and (C- and I-) BGF using la, and 
SPDF and A-RACF using Rq. The examples all build on a basic IMS end-to-end signalling flow between two SIP 
end-points (Phone A and Phone B in clauses 6.1.1 and 6.2.1). The signalling flow without IBCF operations 
(figure 6.1.1) is described in clause 6.1 and involves at the IMS level two P-CSCF entities and one S-CSCF entity. The 
involvement of IBCF entities at the IMS level is based on the same signalling flow but with two S-CSCF entities and 
two IBCF entities (figure 6.2.1). The specific interactions involving IBCF entities are described in clause 6.2. 

6.1 Basic IMS end-to-end signalling flow 

Figure 6.1.1 illustrates the example network architecture. 




Phone B 



Figure 6.1.1 : IMS end-to-end signalling flow between two SIP end-points - without IBGF 

As indicated in [1] RTP should use an even destination port number and the corresponding RTCP stream should use the 
next higher (odd) destination port number. Following these recommendations the addresses and ports used in the 
example are as follows: 



Ai = 192.168.0.2:23942 for RTP and 192.168.0.2:23943 for RTCP. 
A2 = 192.168.0.1:4444 for RTP and 192.168.0.1:4445 for RTCP. 
A3 = 10.0.0.1:2222 for RTP and 10.0.0.1:2223 for RTCP. 
Bj = 192. 168. 1.2:29792 for RTP and 192. 168. 1.2:29793 for RTCP. 
B2= 192.168.1.1:3332 for RTP and 192.168.1.1:3333 for RTCP. 
B3= 10.0.0.2: 11 10 for RTP and 10.0.0.2:1111 for RTCP. 



The RTP stream is assumed to consume 96 kbps, while the RTCP is assumed to use 8 kbps. No packet loss occurs. The 
statistics are approximately chosen in the message flows. Identifiers used in the examples are selected to follow the 
formats defined for the respective protocols. 
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Figure 6.1.2 focuses on the two C-BGF entities, which are H.248-controlled MG entities, and highlights the "BGF 
Connection Model", which relates to single H.248 Contexts with each two H.248 IP terminations. It has to be noted that 
figure 6.1.2 is just an example, indicating only the single H.248 Stream solution for RTP and RTCP together. 



SIP UA: 
Phone A 



SIP UA: 
Phone B 




This H.248 Context is 
created in steps 3/4, and again 
modified in steps 43/44. 



-). Tinis H.248 Context is 

created in steps 1 1/12, and again 
modified in steps 19/20 & 51/52. 



NOTE: The picture highlights the BGF Connection models. 

Figure 6.1.2: Simplified network model with focus on BGF entities only 
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6.1.1 Session setup 



C-BGFA S-CSCF OBGFB 



9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
21 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
« 
41 
42 
43 
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Figure 6.1.1.1 : IMS end-to-end signalling chart between two SIP end-points - session setup 
Table 6.1.1.1 : IMS end-to-end messages between two SIP end-points - session setup 
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Step 


Protocol 


Interface 


From 


To 


Message 


1 


SIP 




Phone A 


P-CSCF A 


INVITE B 


INVITE sip: user_b@example.com SIP/2.0 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max- Forwards: 7 

Route : <sip :p-cscf -a . example . com; lr> 

From: User A <sip:user a@example . com> ; tag=372183 

To: User B <sip:user b@example . com> 

Call -ID: 3 981742 93@phone-a.example.com 

CSeq: 1 INVITE 

Contact : <sip:user_a@phone- a. example . com> 

Content-Type: application/sdp 

Content -Length: 12 9 

v=0 

o=user a 2890844526 2890842807 IN IP4 phone-a.example.com 
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Step I Protocol | Interface | From | To | Message 



s = - 

c=IN IP4 192.1G8.0.2 

t = 

m=audio 2 3 942 RTP/AVP 

a=sendrecv 



JSIP \ I P-CSCF A I Phone A 1 1 00 Trying 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(Sphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



IDIAMETER [Gq; |P-CSCFA |SPDFA |AAR 



The P-CSCF uses the IP address registered for signalling as the Globally-Unique-Address. 

The Gq' protocol specification [4] and the Rq protocol specification [3] both specify rules for how to assign numbers to 

the Flow-Number AVP and Media-Component-Number AVP respectively. The Flow-Number AVP is specified as the 

ordinal number of the IP flow(s), assigned according to the rules in annex C of [2] and the IVIedia-Component-Number 

AVP is specified as the ordinal number of the media component, assigned according to the rules in annex C of [2]. In 

annex C.1 in [2] it is stated that both these numbers are to start at 1 for a given session. 

Following the rules defined in clause 4, the P-CSCF translates the single codec indicated in the m= line to bandwidth 

using locally configured information on the mapping between codec and bandwidth taking account for the packetization 

overhead (i.e. AVP/RTP translates to PCMU/8000, which is 64 kbps that becomes 96 kbps plus 8 kbps with 

packetization overhead). 

Given the reception of a=sendrecv in the SDP the P-CSCF issues a bi-directional reservation request to the SPDF. 

Following the rules given in clause 5.2.1 .3 the Binding-Information AVPs are set to 0.0.0.0 and respectively since no 

addresses or ports at the core side is available. 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "p-cscf -a. example . com; 13815C; 391" > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "p-cscf -a. example . com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit out 17 from any to 192.168.0.2 23942" ] 
[ Flow-Description = "permit in 17 from any to any" ] 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 
[ Max-Requested-Bandwidth-UL = 96000 ] 
] 

[ Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 192.168.0.2 23943" ] 
[ Flow-Description = "permit in 17 from any to any" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
[ Max-Requested-Bandwidth-UL = 8000 ] 
] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = DISABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

{ Framed- IP-Address = 192.168.0.2 } 
{ Port-Number = 23942 } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 0.0.0.0 } 
{ Port -Number = } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 192.168.0.2 } 
{ Port-Number = 23943 } 
] 
[ V4 -Transport -Address = 
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Step I Protocol | Interface | From | To | Message 



Framed- IP-Address = 0.0.0.0 } 
{ Port -Number = } 
] 
} 
] 

[ Reservation-Priority = DEFAULT (0) ] 
[ Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.0.2 ] 
[ Address-Realm = "example.com" ] 
] 
[ Authorization-Lifetime = 450 ] 



H.248 la SPDFA C-BGFA Add terminations 



The default value of H.248 StreamMode is "Inactive", the H.248 Streams are by default created as "Inactive". Hence, the 

IVIode descriptor is omitted in this message. 

The Diameter <AA-Request> for an RTP flow and an RTCP flow is translated here into an H.248 Termination/Stream 

model by using the default RTP Specific behaviour of the BGF. Alternatively, the RTP and RTCP flows could be mapped 

on two separate H.248 Streams (clause 5.17.1.1 in [7]). 

The specific behaviour is controlled via property gm/rsb "RTP Specific Behaviour". In this example, this property is 

enabled by default; hence the gm/rsb descriptor is not included in the message. 



MEGACO/3 [spdf-a.example.com] : 55555 
Transaction = 1 { 
Context = ${ 

Add = ip/l/ifl/$ { /* NOTE 1 */ 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- $ - - 
c=IN IP4 $ 
b=AS:104 

}, 
Remote { 

v=0 

m=- 23942 - - 

c=IN IP4 192.168.0.2 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/$ { 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- $ - - 
c=IN IP4 $ 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
} /* Transaction */ 

NOTE: The wildcard CHOOSE options are very limited, only "Id" may be wildcarded (see Table 4/ES 283 01 8 
(2006-06)). ^ 



IH.248 [la IC-BGFA |SPDFA [Reply (Add) 



It should be noted that H.248 replies typically contain only new information not previously given in preceding H.248 
request triggering the replies. The following H.248 message and all other H.248 replies shown in the present document 
includes however all information offered in the H.248 request together with the new information created by the BGF. The 
complete information is shown to clearly illustrate the interaction between the SPDF and the BGF for the depicted 
scenario. 



MEGACO/3 [abgf-a.example.com] : 55555 
Reply = 1 { 

Context = 1 { 

Add = ip/l/ifl/1 { 
Media { 

Stream = 1 { 
Local { 
v=0 
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Step 



Protocol 



Interface 



From 



To 



Message 



m=- 4444 - - 
C=IN IP4 192 .168 . 
b=AS:104 

}, 
Remote { 

v=0 

m=- 23942 - - 

C=IN IP4 192 .1S8 . 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/l { 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 2222 - - 
C=IN IP4 10 . . .: 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
/* Reply */ 



0.2 



DIAMETER 



jm. 



SPDFA 



A-RACF A 



AAR 



The A-RACF does not need the port numbers in this scenario since it does not interrogate any entity over Re or Ra 
(which are not defined for RAGS release 1). These numbers are however included anyway since that is the desired 
default behaviour. That is, the SPDF should not need to keep track of whether or not port numbers are needed. 
It should be noted that although source IP addresses are not provided the A-RACF can determine the sources from the 
Globally-Unique-Address of the subscriber (i.e. the A-RACF knows the location of each subscriber as this identifier 
comes associated with a Logical-Access-ID from the CLF over e4). 



<AA-Request> 



Diameter Header: 2 65, REQ, PXY > 
Session-Id = "spdf -a. example . com;429C3 , -412 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-a.example.com" } 
Origin-Realm = "example.com" } 
Destination-Realm = "example.com" } 
Media-Component-Description = 
{ Media-Component -Number 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 
[ Flow-Description = 
[ Flow-Description = 
[ Flow-Usage = N0_INF0RMATI0N (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 
[ Max-Requested-Bandwidth-UL = 96000 ] 



1 } 



permit out 17 from any to 192.168.0.2 23942" 
permit in 17 from any to any" ] 



] 



Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 192.168.0.2 23943" 
[ Flow-Description = "permit in 17 from any to any" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
[ Max-Requested-Bandwidth-UL = 8000 ] 



AF -Application- Identifier 
Media-Type = AUDIO (0) ] 



"RQ SAMPLE APP"] 



[ Flow-Status = DISABLED ] 

[ Reservation-Priority = DEFAULT (0) 

] 

[ Reservation-Priority = DEFAULT (0) ] 

[ Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.0.2 ] 
[ Address-Realm = "example.com" ] 

] 

[ Authorization-Lifetime = 450 ] 



DIAMETER 



JM. 



A-RACF A 



SPDFA 



AAA 



<AA-Answer> 



< Diameter Header: 2 65, PXY > 
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Step 



Protocol 



Interface 



From 



To 



Message 



< Session-Id = "spdf -a. example . com;429C3 , -412 " 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "aracf-a.example.com" } 

{ Origin-Realm = "example.com" } 

[ Result-Code = DIAMETER_SUCCESS (2001) ] 

[ Authorization-Lifetime = 450 ] 

[ Auth-Grace-Period = 10 ] 



DIAMETER 



iGq' 



SPDF A 



P-CSCFA 



AAA 



<AA-Answer> 



Diameter Header: 2 65, PXY > 

Session-Id = "p-cscf -a. example . com; 13815C; 391" 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-a.example.com" } 
Origin-Realm = "example.com" } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
Binding-Information = 
{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 192.168.0.2 } 

Port-Number = 23942 } 



] 



V4 



V4 



] 



Transport -Address = 
Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 192. 
Port-Number = 23943 } 

Transport -Address = 
Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 



.0.2 } 



Binding-Output-List = 

[ V4-Transport-Address = 
Framed- IP-Address = 
Port -Number = 2222 

V4 -Transport -Address = 
Framed- IP-Address = 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 
Port -Number = 2223 

V4 -Transport -Address = 
Framed- IP-Address = 
Port -Number = } 



Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 



10.0.0.1 } 



0.0.0.0 } 



10.0.0.1 } 



0.0.0.0 } 



SIP 



P-CSCFA 



S-CSCF 



INVITEE 



INVITE sip:user_b(aexample.com SIP/2.0 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 69 

Record- Route : <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_a®phone- a. example . com> 

Content-Type: application/sdp 

Content -Length: 12 9 



o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s = - 

c=IN IP4 10.0.0.1 

t = 
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Step I Protocol | Interface | From | To | Message 



m=audio 2222 RTP/AVP 
a=sendrecv 



10 ISIP \ IS-CSCF IP-CSCFA 1 100 Trying 



SIP/2.0 100 Trying 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



11 SIP S-CSCF P-CSCF B INVITEE 



INVITE sip:user_b(aexample.com SIP/2.0 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 68 

Record- Route : <sip: s-cscf .example . com; lr>, <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_a(aphone- a. example . com> 

Content-Type: application/sdp 

Content -Length: 125 

v=0 

o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s = - 

c=IN IP4 10.0.0.1 

t = 

m=audio 2222 RTP/AVP 

a=sendrecv 



12 |SIP \ IS-CSCF IP-CSCFB |100 Trying 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



13 IDIAIVIETER [Gq; | P-CSCF B |SPDF B |AAR 



It should be noted that the IP address registered for signalling, which equals the Globally Unique IP Address, cannot be 
safely assumed to also be the source IP address for media. Hence, using this address as the source address for media 
may cause problems in case source filtering is applied. For this reason no source IP address is provided although the IP 
address registered for signalling to Phone B may be the same source IP address used for media. 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "p-cscf -b. example . com;481C43 ; 583 " > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "p-cscf -b. example . com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit in 17 from any to any" ] 
[ Flow-Description = "permit out 17 from any to any" ] 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-UL = 96000 ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 



] 



Media-Sub-Component = 
{ Flow-Number = 2 } 
[ Flow-Description = "permit in 17 from any to any" ] 
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Step Protocol Interface From To Message 


[ Flow-Description = "permit out 17 from any to any" ] 


[ Flow-Usage = RTCP (1) ] 


[ Max-Requested-Bandwidth-UL = 8000 ] 


[ Max-Requested-Bandwidth-DL = 8000 ] 
1 


J 

[ AF-Application-Identifier = "GQPRIME_SAMPLE_APP"] 


[ Media-Type = AUDIO (0) ] 


[ Flow-Status = DISABLED ] 


[ Reservation-Priority = DEFAULT (0) ] 
1 


J 

[ Binding-Information = 


{ Binding- Input -List = 


[ V4 -Transport -Address = 


{ Framed- IP-Address = 0.0.0.0 } 


{ Port -Number = } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 10.0.0.1 } 


{ Port -Number = 2222 } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 0.0.0.0 } 


{ Port -Number = } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 10.0.0.1 } 


{ Port -Number = 2223 } 
] 
} 
] 
[ Reservation-Priority = DEFAULT (0) ] 


[ Globally-Unique-Address = 


[ Framed- IP-Address = 192.168.1.2 ] 


[ Address-Realm = "example.com" ] 
1 


J 

[ Authorization-Lifetime = 450 ] 


14 |H.248 |la |SPDF B |C-BGF B |Add terminations 


MEGACO/3 [spdf-b.example.com] : 43 924 


Transaction = 1 { 


Context = $ { 


Add = ip/l/ifl/$ { 


Media { 


Stream = 1 { 


Local { 


v=0 


m=- $ - - 


C=IN IP4 $ 


b=AS:104 

} 
} /* Stream */ 


} /* Media */ 


} /* Add */ 


Add = ip/l/if2/$ { 


Media { 


Stream = 1 { 


Local { 


v=0 


m=- $ - - 


C=IN IP4 $ 


b=AS:104 

}, 
Remote { 


v=0 


m=- 2222 - - 


C=IN IP4 10.0.0.1 


b=AS:104 

} 
} /* Stream */ 


} /* Media */ 


} /* Add */ 


} /* Context */ 


} /* Transaction */ 
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15 



H.248 



la 



C-BGF B 



SPDFB 



Reply (Add) 



MEGACO/3 [abgf-b.example.com] : 43924 
Reply = 1 { 

Context = 1 { 

Add = ip/l/ifl/l{ 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 3332 - - 
c=IN IP4 192.168.1.1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/l{ 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 1110 - - 
c = IN IP4 10 . . .2 
b=AS:104 

}, 

Remote { 
v=0 

m=- 2222 - - 
c=IN IP4 10 .0 .0 .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
} /* Reply */ 



16 



DIAMETER 



JM. 



SPDFB 



A-RACF B 



AAR 



The A-RACF determines the access line from the Globally-Unique-Address AVP since the source and destination IP 
addresses for that reservation endpoint are not given in the request (i.e. they are both set to "any"). 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "spdf -b. example . com;41295 ; 512 
{ Auth-Application-Id = 16777222 (Gq) } 
{ Origin-Host = "spdf-b.example.com" } 
{ Origin-Realm = "example.com" } 
{ Destination-Realm = "example.com" } 
[ Media-Component-Description = 
{ Media-Component -Number 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 
[ Flow-Description = 
[ Flow-Description = 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-UL = 96000 
[ Max-Requested-Bandwidth-DL = 96000 



1 } 



permit in 17 from any to 192.168 
permit out 17 from any to any" ] 



] 



1.1 3332" 



] 



Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit in 17 from any to 192.168 
[ Flow-Description = "permit out 17 from any to any" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-UL = 8000 ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 



1.1 3333" 



AF -Application- Identifier 
AUDIO (0) ] 



" RQ_SAMPLE_APP " ] 



[ Media-Type 

[ Flow-Status = DISABLED ] 

[ Reservation-Priority = DEFAULT (0) ] 

Reservation-Priority = DEFAULT (0) ] 

Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.1.2 ] 
[ Address-Realm = "example.com" ] 
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Interface From To 




Message 


[ Authorization-Lifetime = 450 ] 


17 IDIAMETER 


|Rq lA-RACFB |SPDF B 


|AAA 




<AA-Answer> ::= < 


Diameter Header: 2 65, PXY > 






< 


Session-Id = "spdf -b. example . com;41295 ; 512 " > 








Auth-Application-Id = 16777222 (Gq) } 








Origin-Host = "aracf-b.example.com" } 








Origin-Realm = "example.com" } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 






18 IDIAMETER 


|Gq' ISPDFB |P-CSCFB 


|AAA 




<AA-Answer> ::= < 


Diameter Header: 2 65, PXY > 






< 


Session-Id = "p-cscf -b. example . com;481C43 ; 583 


> 






Auth-Application-Id = 16777222 (Gq) } 








Origin-Host = "spdf-b.example.com" } 






[ 
[ 


Origin-Realm = "example.com" } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
Binding-Information = 
{ Binding- Input -List = 

[ V4 -Transport -Address = 

{ Framed- IP-Address = 0.0.0.0 } 

{ Port -Number = } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 10.0.0.1 } 

{ Port -Number = 2222 } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 0.0.0.0 } 

{ Port -Number = } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 10.0.0.1 } 

{ Port -Number = 2223 } 
] 

} 

[ Binding-Output-List = 

[ V4 -Transport -Address = 

{ Framed- IP-Address = 0.0.0.0 } 
{ Port -Number = } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 192.168.1.1 } 
{ Port -Number = 3332 } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 0.0.0.0 } 
{ Port -Number = } 
] 
[ V4 -Transport -Address = 

{ Framed- IP-Address = 192.168.1.1 } 
{ Port -Number = 3333 } 
] 
] 
Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 






19 ISIP 


1 1 P-CSCF B 1 Phone B 


llNVITEB 




INVITE sip:user b@example.com SIP/2.0 






Via 


SIP/2 . 0/UDP p-cscf -b.example.com : 5 060; branch=z9hG4bKslppO 






Via 


SIP/2. 0/UDP £ 


-cscf .example . com: 5 06 ;branch=z9hG4bKralar 






Via 


SIP/2 . 0/UDP p-cscf -a. example. com: 5 060; branch=z9hG4bKvp2yml 






Via 


SIP/2 . 0/UDP phone -a. example. com: 5 06 0;branch=z9hG4bK74b03 






Max-Forwards: 67 








Record- Route : <sip:p-cscf-b. example . com; lr>,<sip:s-cscf .example . 


com; lr>, <sip 


p-cscf- 


a. example . com; lr> 








From: User A <sip 


user aOexample . com>; tag=372183 






To: User B <sip:user boexample . com> 






Call-ID: 39817429: 


Ophone-a. example . com 






CSeq: 1 INVITE 








Contact: <sip:user aOphone-a. example . com> 
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Step I Protocol | Interface | From | To | Message 



Content-Type: application/sdp 
Content -Length: 12 8 

v=0 

o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s=- 

c=IN IP4 192.1G8.1.1 

t = 

m=audio 3332 RTP/AVP 

a=sendrecv 



20 [SIP \ [Phone B [P-CSCFB [180 Ringing 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP p-cscf-b . example . com: 5060 ;branch=z9hG4bKslppO 
Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 
Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 
Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Record- Route : <sip: p-cscf-b. example . com; lr>,<sip: s-cscf .example . com; lr>,<sip:p-cscf- 
. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93@phone-a.example.com 

Contact : <sip:user_b@phone-b. example . com> 

CSeq: 1 INVITE 

Content-Type: application/sdp 

Content -Length: 



21 [SIP \ [P-CSCFB [S-CSCF [180 Ringing 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Record- Route : <sip: s-cscf .example . com; lr>, <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user_a@example . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93@phone-a.example.com 

Contact : <sip:user_b@phone-b. example . com> 

CSeq: 1 INVITE 

Content-Type: application/sdp 

Content -Length: 



22 [SIP \ [S-CSCF [P-CSCF A [180 Ringing 



SIP/2.0 180 Ringing 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Record- Route : <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user_a@example . com>; tag=372183 

To: User B <sip :user_b@example . com> 

Call -ID: 3 981742 93@phone-a.example.com 

Contact : <sip:user_b@phone-b. example . com> 

CSeq: 1 INVITE 

Content-Type: application/sdp 

Content -Length: 



23 [SIP \ [P-CSCF A [Phone A [180 Ringing 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Record- Route : <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user_a@example . com>; tag=372183 

To: User B <sip :user_b@example . com> 

Call -ID: 3 981742 93@phone-a.example.com 

Contact : <sip:user_b@phone-b. example . com> 

CSeq: 1 INVITE 

Content-Type: application/sdp 

Content -Length: 



24 [SIP \ [Phone B [P-CSCFB [200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 
Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 
Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 
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Step I Protocol | Interface | From | To | Message 



via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 70 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_b(aphone-b. example . com> 

Content-Type: application/sdp 

Content -Length: 119 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s = - 

c=IN IP4 192.168.1.2 

t = 

m=audio 29792 RTP/AVP 



25 IDIAMETER [Gq; |P-CSCF B |SPDF B |AAR (Modify) 



In this AAR modifying an existing session both in and out Flow-Description AVPs and both the 
IVIax-Requested-Bandwidth-UL and the IVlax-Requested-Bandwidth-DL are provided in the request. Although this may 
seem be redundant information (as the in Flow-Description AVP and IVIax-Requested-Bandwidth-UL are already provided 
to RAGS) the Gq' specification does not explicitly allow any of those AVPs to be omitted. Hence, they are all included. 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "p-cscf -b. example . com;481C43 ; 583 " > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "p-cscf -b. example . com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit out 17 from any to 192.168.1.2 29792" ] 
[ Flow-Description = "permit in 17 from any to 192.168.1.1 3332" ] 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 
[ Max-Requested-Bandwidth-UL = 96000 ] 
] 

[ Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 192.168.1.2 29793" ] 
[ Flow-Description = "permit in 17 from any to 192.168.1.1 3333" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
[ Max-Requested-Bandwidth-UL = 8000 ] 
] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = ENABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 192.168.1.2 } 
Port-Number = 29792 } 



] 



V4 



V4 



Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2222 } 

Transport -Address = 
Framed- IP-Address = 192.168.1.2 
Port-Number = 29793 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2223 } 



] 



} 

] 

[ Reservation-Priority = DEFAULT (0) ] 

[ Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.1.2 
[ Address-Realm = "example.com" ] 
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Step I Protocol | Interface | From | To | Message 



] 

[ Authorization-Lifetime = 450 ] 



26 IH.248 [la |SPDF B |C-BGF B |Modify terminations 



MEGACO/3 [spdf-b.example.com] : 43 924 
Transaction = 2 { 
Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 3332 - - 
c=IN IP4 192.168.1.1 
b=AS:104 

} 
Remote { 

v=0 

m=- 29792 - - 

c=IN IP4 192.168.1.2 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

Local { 
v=0 

m=- 1110 - - 
C=IN IP4 10 .0 .0 .2 
b=AS:104 

}, 

Remote { 
v=0 

m=- 2222 - - 
C=IN IP4 10 .0 .0 .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Transaction */ 



27 lH.248 [la |C-BGF B [SPDF B [Reply (Modify) 



MEGACO/3 [abgf-b.example.com] : 43924 
Reply = 2 { 

Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 3332 - - 
c=IN IP4 192.168.1.1 
b=AS:104 

}, 
Remote { 

v=0 

m=- 29792 - - 

c=IN IP4 192.168.1.2 

b=AS:104 
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} /* stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 
Local { 

v=0 

m=- 1110 - - 

c = IN IP4 10 .0 .0 .2 

b=AS:104 

}, 
Remote { 

v=0 

m=- 2222 - - 

c=IN IP4 10 .0 .0 .1 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Reply */ 
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DIAMETER 



jm. 



SPDFB 



A-RACF B 



|AAR (Modify) 



<AA-Request> : ; 



Diameter Header: 265, REQ, PXY > 
Session-Id = "spdf -b. example . com;41295 ; 512 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-b.example.com" } 
Origin-Realm = "example.com" } 
Destination-Realm = "example.com" } 
Media-Component-Description = 
{ Media-Component -Number 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 
[ Flow-Description = 
[ Flow-Description = 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-UL = 96000 ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 



1 } 



permit out 17 from any to 192.168.1.2 29792" ] 
permit in 17 from any to 192.168.1.1 3332" ] 



] 



[ Media-Sub-Component = 

{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 192.168.1.2 29793" ] 

[ Flow-Description = "permit in 17 from any to 192.168.1.1 3333" ] 

[ Flow-Usage = RTCP(l) ] 

[ Max-Requested-Bandwidth-UL = 8000 ] 

[ Max-Requested-Bandwidth-DL = 8000 ] 
] 

[ AF-Application-Identif ier = "RQ_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = ENABLED } 
[ Reservation-Priority = DEFAULT (0) ] 

Reservation-Priority = DEFAULT (0) ] 
Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.1.2 ] 

[ Address-Realm = "example.com" ] 

Authorization-Lifetime = 450 ] 
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DIAMETER 



|Rq 



A-RACF B 



SPDFB 



|AAA (Modify) 



<AA-Answer> ::= < Diameter Header: 265, PXY > 

< Session-Id = "spdf -b. example . com;41295 ; 512 " 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "aracf-b.example.com" } 

{ Origin-Realm = "example.com" } 

[ Result-Code = DIAMETER_SUCCESS (2001) ] 

[ Authorization-Lifetime = 450 ] 

[ Auth-Grace-Period = 10 ] 
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DIAMETER 



Gi 



SPDFB 



P-CSCF B 



AAA (Modify) 



<AA-Answer> 



< Diameter Header: 2 65, PXY > 

< Session-Id = "p-cscf -b. example . com;481C43 ; 583 " 
{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "spdf-b.example.com" } 
{ Origin-Realm = "example.com" } 
[ Result-Code = DIAMETER_SUCCESS (2001) ] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 192.168.1.2 } 
Port-Number = 29792 } 



] 



V4 



V4 



V4 



V4 -Transport -Address = 

Framed- IP-Address = 10.0.0. 
Port -Number = 2222 } 

Transport -Address = 
Framed- IP-Address = 192. 16E 
Port-Number = 29793 } 

V4 -Transport -Address = 

Framed- IP-Address = 10.0.0. 
Port -Number = 2223 } 



Binding-Output-List = 10.0.0.2 



Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1110 } 

Transport -Address = 
Framed- IP-Address = 192.168.1.] 
Port -Number = 3332 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1111 } 



Transport -Address = 
Framed- IP-Address = 192. 16E 
Port -Number = 3333 } 



Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 



.1.1 } 



31 



SIP 



P-CSCF B 



S-CSCF 



|200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 69 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_b@phone-b. example . com> 

Content-Type: application/sdp 

Content -Length: 12 6 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s = - 

c=IN IP4 10.0.0.2 

t = 

m=audio 1110 RTP/AVP 

a=sendrecv 



32 



SIP 



S-CSCF 



P-CSCF A 



|200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 
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Step Protocol Interface From To Message 


via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 


Max-Forwards: 68 


From: User A <sip:user aOexample . com>; tag=372183 


To: User B <sip:user boexample . com> 


Call -ID: 3 981742 93(aphone-a. example, com 


CSeq: 1 INVITE 


Contact : <sip:user_b(Sphone-b. example . com> 


Content-Type: application/sdp 


Content -Length: 126 


v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 


s = - 

c=IN IP4 10.0.0.2 


t = 


m=audio 1110 RTP/AVP 


a=sendrecv 


33 IDIAMETER |Gq' |P-CSCFA |SPDFA |AAR (Modify) 


<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 


< Session-Id = "p-cscf -a. example . com; 13815C; 391" > 


{ Auth-Application-Id = 16777222 (Gq) } 


{ Origin-Host = "p-cscf -a. example . com" } 


{ Origin-Realm = "example.com" } 


{ Destination-Realm = "example.com" } 


[ Media-Component-Description = 


{ Media-Component -Number = 1 } 


[ Media-Sub-Component = 


{ Flow-Number = 1 } 


[ Flow-Description = "permit in 17 from any to any" ] 


[ Flow-Description = "permit out 17 from any to 192.168.0.2 23942" ] 


[ Flow-Usage = NO_INFORMATION (0) ] 


[ Max-Requested-Bandwidth-UL = 96000 ] 


[ Max-Requested-Bandwidth-DL = 96000 ] 
1 


J 

[ Media-Sub-Component = 


{ Flow-Number = 2 } 


[ Flow-Description = "permit in 17 from any to any" ] 


[ Flow-Description = "permit out 17 from any to 192.168.0.2 23943" ] 


[ Flow-Usage = RTCP(l) ] 


[ Max-Requested-Bandwidth-UL = 8000 ] 


[ Max-Requested-Bandwidth-DL = 8000 ] 
1 


J 

[ AF-Application-Identifier = "GQPRIME_SAMPLE_APP"] 


[ Media-Type = AUDIO (0) ] 


[ Flow-Status = ENABLED ] 


[ Reservation-Priority = DEFAULT (0) ] 
1 


J 

[ Binding- Information = 


{ Binding-Input-List = 


[ V4 -Transport -Address = 


{ Framed- IP-Address = 192.168.0.2 } 


{ Port-Number = 23942 } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 10.0.0.2 } 


{ Port -Number = 1110 } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 192.168.0.2 } 


{ Port-Number = 23943 } 
1 


J 

[ V4 -Transport -Address = 


{ Framed- IP-Address = 10.0.0.2 } 


{ Port -Number = 1111 } 
] 
} 
] 
[ Reservation-Priority = DEFAULT (0) ] 


[ Globally-Unique-Address = 


[ Framed- IP-Address = 192.168.0.2 ] 


[ Address-Realm = "example.com" ] 
1 


J 

[ Authorization-Lifetime = 450 ] 
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la 



SPDFA 



C-BGFA 



I Modify Terminations A (A to B) 



MEGACO/3 [spdf-a.example.com] : 55555 
Transaction = 2 { 
Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 4444 - - 
C=IN IP4 192 .1S8 .0.1 
b=AS:104 

}, 
Remote { 

v=0 

m=- 23942 - - 

C=IN IP4 192 .1S8 .0.2 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 2222 - - 
c = IN IP4 10 .0 .0 .1 
b=AS:104 

}, 

Remote { 
v=0 

m=- 1110 - - 
c = IN IP4 10 . . .2 
b=AS:104 



} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Transaction */ 
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la 



C-BGFA 



SPDFA 



[Reply (IVIodify) 



MEGACO/3 [abgf-a.example.com] : 55555 
Reply = 2 { 

Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 4444 - - 
c=IN IP4 192.168.0.1 
b=AS:104 

}, 
Remote { 

v=0 

m=- 23942 - - 

c=IN IP4 192.168.0.2 

b=AS:104 
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} /* stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 
Local { 

v=0 

m=- 2222 - - 

C=IN IP4 10 .0 . . 

b=AS:104 

}, 
Remote { 

v=0 

m=- 1110 - - 

C=IN IP4 10 . . . 

b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Reply */ 
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DIAMETER 



jm. 



SPDFA 



A-RACF A 



|AAR (Modify) 



<AA-Request> 



Diameter Header: 265, REQ, PXY > 
Session-Id = "spdf -a. example . com;429C3 , -412 " > 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-a.example.com" } 
Origin-Realm = "example.com" } 
Destination-Realm = "example.com" } 
Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 

{ Flow-Number = 1 } 

[ Flow-Description = "permit out 17 from any to 192.168.0.2 23942" 

[ Flow-Description = "permit in 17 from any to 192.168.0.1 4444" ] 

[ Flow-Usage = NO_INFORMATION (0) ] 

[ Max-Requested-Bandwidth-UL = 96000 ] 

[ Max-Requested-Bandwidth-DL = 96000 ] 



] 



Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 192. 16f 
[ Flow-Description = "permit in 17 from any to 192.168. 
[ Flow-Usage = RTCP(l) ] 
[ Max-Requested-Bandwidth-UL = 8000 ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 



RQ_SAMPLE_APP"] 



.0.2 23943" 
0.1 4445" ] 



[ AF-Application-Identif ier 

[ Media-Type = AUDIO (0) ] 

[ Flow-Status = ENABLED ] 

[ Reservation-Priority = DEFAULT (0) ] 

Reservation-Priority = DEFAULT (0) ] 

Globally-Unique-Address = 

[ Framed- IP-Address = 192.168.0.2 ] 
[ Address-Realm = "example.com" ] 

Authorization-Lifetime = 450 ] 
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DIAMETER 



|Rq 



A-RACF A 



SPDFA 



|AAA (Modify) 



<AA-Answer> ::= < Diameter Header: 265, PXY > 

< Session-Id = "spdf -a. example . com;429C3 , -412 " 
{ Auth-Application-Id = 16777222 (Gq) } 
{ Origin-Host = "aracf-a.example.com" } 
{ Origin-Realm = "example.com" } 
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[ Result -Code = DIAMETER_SUCCESS 
[ Authorization-Lifetime = 450 ] 
[ Auth-Grace- Period = 10 ] 



(2001) ] 
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DIAMETER 



iGq' 



SPDFA 



P-CSCFA 



|AAA (Modify) 



<AA-Answer> 



< Diameter Header: 265, PXY > 

< Session-Id = "p-cscf -a. example . com; 13815C; 391" 
{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "spdf-a.example.com" } 
{ Origin-Realm = "example.com" } 
[ Result-Code = DIAMETER_SUCCESS (2001) ] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 192.168.0.2 } 
Port-Number = 23942 } 



] 

[ V4 



[ V4 



V4 



V4 



Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1110 } 

Transport -Address = 
Framed- IP-Address = 192.168.0.2 
Port-Number = 23943 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1111 } 



Binding -Output -List 



Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2222 } 

Transport -Address = 
Framed- IP-Address = 192.168.0.1 
Port -Number = 4444 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2223 } 



Transport -Address = 
Framed- IP-Address = 192. 16E 
Port -Number = 4445 } 



.0.1 } 



Authorization-Lifetime 
Auth-Grace-Period = 10 



450 ] 
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SIP 



P-CSCFA 



Phone A 



|200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 67 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(Sphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_b(aphone-b. example . com> 

Content-Type: application/sdp 

Content -Length: 12 9 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s = - 

c=IN IP4 192.168.0.1 

t = 

m=audio 4444 RTP/AVP 

a=sendrecv 
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SIP 



Phone A 



P-CSCF A 



ACK 



ACK sip:user_b@example . com SIP/2.0 

Via: SIP/2. 0/UDP phone-a . example . com: 50G0 ;branch=z9hG4bK74b03 

Max-Forwards: 70 

Route : <sip:p-cscf -a. example . com; lr>,<sip:s-cscf .example . com; lr>, <sip:p-cscf-b. example . com; lr> 

From: User A <sip:user_a@example . com>; tag=348123 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 ACK 

Content -Length: 



41 



SIP 



P-CSCF A 



S-CSCF 



ACK 



ACK sip:user_b(aexample . com SIP/2.0 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 69 

Route : <sip:s-cscf .example . com; lr>, <sip:p-cscf-b. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=348123 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 ACK 

Content -Length: 



42 



SIP 



S-CSCF 



P-CSCF B 



ACK 



ACK sip:user_b@example . com SIP/2.0 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 68 

Route : <sip:p-cscf-b. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=348123 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93®phone-a. example. com 

CSeq: 1 ACK 

Content -Length: 
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SIP 



P-CSCF B 



Phone B 



ACK 



ACK sip:user_b@example . com SIP/2.0 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 

Via: SIP/2 . 0/UDP phone-a. example. com:5060; branch=z9hG4bK74b03 

Max-Forwards: 67 

From: User A <sip:user_a@example . com>; tag=348123 

To: User B <sip :user_b@example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 ACK 

Content -Length: 
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6.1 .2 Session termination 



PhoneA P-CSCFA SPDFA A-RACFA C-BGFA S-CSCF C-BGFB A-RACFB SPDFB P-CSCFB PtioneB 
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Figure 6.1.2.1 : MS end-to-end signalling chart between two SIP end-points - session teardown 
Table 6.1.2.1 : IIVIS end-to-end messages between two SIP end-points - session teardown 



Step 



Protocol 



Interface 



From 



To 



Message 
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SIP 



Phone B 



P-CSCF B 



BYE 



BYE sip :user_a®example . com SIP/2.0 

Via: SIP/2 . 0/UDP phone -b. example .com: 5060 ;branch=z9hG4bKjwaf cb9 

Max-Forwards: 70 

Route : <sip:p-cscf-b. example . com; lr>,<sip:s-cscf. example . com; lr>,<sip:p-cscf-a. example . com; lr> 

From: User B <sip :user_b@example . com>; tag=4fxdcel21s 

To: User A <sip : user_a@example . com> 

Call-ID : 398174293@phone-a . example . com 

CSeq: 1 BYE 

Content-Length: 



45 



DIAMETER 



iGq' 



P-CSCF B 



SPDFB 



STR 



<ST-Request> ::=< Diameter Header: 275, REQ, PXY > 

< Session-Id = "p-cscf -b. example .com;4BlC43 ; 583 ' 

{ Origin-Host = "p-cscf -b. example . com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 
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H.248 



la 



SPDFB 



C-BGF B 



Subtract termination B 



MEGACO/3 [spdf-b.example.com] : 43 924 
Transaction = 3 { 
Context = 1 { 

Subtract = ip/l/ifl/1 {Audit {Statistics} } 
Subtract = ip/l/if2/l {Auditjstatistics} } 
} /* Context */ 
} /* Transaction */ 
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C-BGF B 
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Step 



Protocol 



Interface 



From 



To 



Message 



MEGACO/3 [abgf-b.example.com] : 43 924 
Reply = 3 { 

Context = 1 { 

Subtract = ip/l/ifl/1 { 
Statistics { 

nt/dur=450000 , ; in milliseconds 

nt/os=5400000 

nt/or=5400000 

gm/dp=0 



Octets Sent 

Octets Received 

number of packets discarded 



} /^ 



} / 
Reply 



Subtract = ip/l/if2/l { 
Statistics { 

nt/dur=450000 
nt/os=450000, 
nt/or=450000, 
gm/dp=0 
} /* Statistics 
} /* Subtract */ 
Context */ 



"I 



in milliseconds 

Octets Sent 

Octets Received 

number of packets discarded 



V 
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DIAMETER 



|Rq 



SPDFB 



A-RACF B 



STR 



<ST-Request> : 



Diameter Header: 2 75, REQ, PXY > 
Session-Id = "spdf -b. example . com;41295 ; 512 ' 
Origin-Host = "spdf-b.example.com" } 
Origin-Realm = "example.com" } 
Destination-Realm = "example.com" } 
Auth-Application-Id = 16777222 (Gq) } 
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DIAMETER 



|Rq 



A-RACF B 



SPDFB 



STA 



<ST-Answer> ::= < Diameter Header: 275, PXY > 

< Session-Id = "spdf -b. example . com;41295 ; 512 ' 

{ Origin-Host = "aracf-b.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 

[ Result-Code = DIAMETER SUCCESS (2001) ] 



50 



DIAMETER 



iGq' 



SPDFB 



P-CSCFB 



STA 



<ST-Answer> : : = 



< Diameter Header: 2 75, PXY > 

< Session-Id = "p-cscf -b. example . com;481C43 ; 583 ' 
{ Origin-Host = "spdf-b.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 

[ Result-Code = DIAMETER SUCCESS (2001) ] 
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SIP 



P-CSCF B 



S-CSCF 



BYE 



BYE sip:user_a@example . com SIP/2.0 

Via: SIP/2. 0/UDP p-cscf -b. example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 69 

Route : <sip:s-cscf .example . com; lr>, <sip: p-cscf -a. example . com; lr> 

From: User B <sip :user_b@example . com> ; tag=4fxdcel21s 

To: User A <sip :user_a@example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 
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SIP 



S-CSCF 



P-CSCF A 



BYE 



BYE sip:user_a(aexample . com SIP/2.0 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 68 

Route : <sip: p-cscf -a. example . com; lr> 

From: User B <sip:user_b@example . com>; tag=4fxdcel21s 

To: User A <sip :user_a@example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 
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Content -Length: 


53 


IDIAMETER 


|Gq' IP-CSCFA |SPDF A 


ISTR 




<ST-Request> : : = < 


Diameter Header: 275, REQ, PXY > 






< 


Session-Id = "p-cscf -a. example . com; 13815C; 391' 


> 




{ 


Origin-Host = "p-cscf -a. example . com" } 






{ 


Origin-Realm = "example.com" } 






{ 


Destination-Realm = "example.com" } 






{ 


Autli-Application-Id = 1G777222 (Gq) } 
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|H.248 


|la ISPDFA IC-BGFA 


Subtract Termination A 




MEGACO/3 [spdf-a.example.com] :5555 






Transaction = 3 { 








Context = 1 








Subtract = 


= ip/l/ifl/l {Audit{Statistics} } 






Subtract = 


= ip/l/if2/l {Audit{Statistics} } 






} /* Context 


*/ 






} /* Transaction * 


/ 
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|H.248 


|la IC-BGFA |SPDF A 


1 Reply 




MEGACO/3 [abgf-a.example.com] : 21398 






Reply = 3 { 








Context = 1 








Subtract = 


= ip/i/ifi/i { 






Statistics { 






nt/c 


ur=450000, 


in milliseconds 






nt/os=5400000, 


Octets Sent 






nt/or=5400000, 


Octets Received 






gm/dp=0 
} 


number of paclcets discarded 






} 

Subtract = 


= ip/l/ifl/2 { 






Statistics { 






nt/c 


ur=450000, 


in milliseconds 






nt/os=450000, 


Octets Sent 






nt/or=450000, 


Octets Received 






gm/dp=0 


number of paclcets discarded 






} /* Statistics */ 






} /* Subtract */ 






} /* Context 


*/ 






} /* Reply */ 
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IDIAMETER 


|Rq ISPDFA |A-RAGF A 


|STR 




<ST-Request> ::=< 


Diameter Header: 2 75, REQ, PXY > 






< 


Session-Id = "spdf -a. example . com;429C3 , -412 " > 






{ 


Origin-Host = "spdf-a.example.com" } 






{ 


Origin-Realm = "example.com" } 






{ 


Destination-Realm = "example.com" } 






{ 


Autli-Application-Id = 1G777222 (Gq) } 
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IDIAMETER 


|Rq lA-RAGFA |SPDF A 


|STA 




<ST-Answer> : : = < 


Diameter Header: 2 75, PXY > 






< 


Session-Id = "spdf -a. example . com;429C3 , -412 " > 








Origin-Host = "aracf-a.example.com" } 








Origin-Realm = "example.com" } 








Destination-Realm = "example.com" } 








Auth-Application-Id = 16777222 (Gq) } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
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IDIAMETER 


|Gq' ISPDFA |P-GSGFA 


ISTA 




<ST-Answer> ::= < 


Diameter Header: 2 75, PXY > 






< 


Session-Id = "p-cscf -a. example . com; 13815C; 391' 


> 






Origin-Host = "spdf-a.example.com" } 








Origin-Realm = "example.com" } 








Destination-Realm = "example.com" } 








Auth-Application-Id = 16777222 (Gq) } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
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SIP 



P-CSCF B 



Phone A 



BYE 



BYE sip:user_a(aexample . com SIP/2.0 

Via: SIP/2. 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 67 

From: User B <sip:user_b(aexample . com>; tag=4fxdcel21s 

To: User A <sip :user_a(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 



60 



SIP 



Phone A 



P-CSCF A 



|200 OK (BYE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 70 

From: User B <sip:user_b@example . com>; tag=4fxdcel21s 

To: User A <sip:user_a®example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 



61 



SIP 



P-CSCF A 



S-CSCF 



|200 OK (BYE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP s-cscf . example . com: 5060 ;branch=z9hG4bKralar 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 69 

From: User B <sip :user_b(aexample . com> ; tag=4f xdcel21s 

To: User A <sip:user_a@example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 



62 



SIP 



S-CSCF 



P-CSCF B 



|200 OK (BYE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 

Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 

Max-Forwards: 68 

From: User B <sip:user_b@example . com>; tag=4fxdcel21s 

To: User A <sip :user_a@example . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 



63 



SIP 



P-CSCF B 



Phone B 



|200 OK (BYE) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP phone -b. example .com: 5060 ;branch=z9hG4bKjwaf cb9 

Max-Forwards: 67 

From: User B <sip :user_b@example . com>; tag=4fxdcel21s 

To: User A <sip : user_a@example . com> 

Call-ID : 398174293@phone-a . example . com 

CSeq: 1 BYE 

Content-Length: 
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6.2 IMS signalling flow involving IBCF entities 




Phone A 



Phone B 



Figure 6.2.1 : IMS end-to-end signalling flow between two SIP end-points - including IBGF 

The additional addresses and ports used in the example compared to the basic call flow described in clause 5.1 are as 
follows: 

• A4 = 10.0.0.3:5554 for RTP and 10.0.0.3:5555 for RTCP. 

• A5 = 10.0.1.1:6666 for RTP and 10.0.1.1:6667 for RTCP. 

• 64= 10.0.0.5:7776 for RTP and 10.0.0.5:7777 for RTCP. 

• 65= 10.0.1.2:8888 for RTP and 10.0.1.2:8889 for RTCP. 
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6.2.1 Session setup 



S-CSCFA 



IBCFA 



SPDFM 



l-BGFA 



l-BGFB 



SPDFBB 



IBCFB 



S-CSCFB 



10.0 

10.1 

10.2 

10.3 

10.4 

10.5 

10.6 

10.7 

10.8 

10.9 

10.10 

10.11 

10.12 

10.13 

31.0 
31.1 
31.2 
31.3 
31.4 
31.5 
31.6 
31.7 
31.8 
31.9 
31.10 

41.0 
41.1 
41.2 



-INVITE B-^ 
-lOOTrying — 



-2000^ 



-ACK- 



-AAFI ► 



-Add ► 

-Fteply 



-AAA- 



-INVITEB- 



-lOOTrying- 



-Add- 



-Add- 



-2000^ 



-AAF! ► 



-Add ► 



-AAA- 



-ACK- 



-AAR- 



-AAA- 



-AAFi- 



-AAA- 



-INVITEB-^ 
-lOOTrying 



-200 OK- 



-ACK ► 



Figure 6.2.1.1 : IMS end-to-end signalling chart for the IBCF - session setup 



10.0 

10.1 

10.2 

10.3 

10.4 

10.5 

10.6 

10.7 

10.8 

10.9 

10.10 

10.11 

10.12 

10.13 

31.0 
31.1 
31.2 
31.3 
31.4 
31.5 
31.6 
31.7 
31.8 
31.9 
31.10 

41.0 
41.1 
41.2 



Table 6.2.1.1 : IMS end-to-end messages for IBCF - session setup 



Step 


Protocol 


Interface 


From 


To 


Message 


10.0 


SIP 




S-CSCF A 


IBCFA 


INVITE B 


INVITE sip:user b@example.com SIP/2.0 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5 06 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 68 

Record- Route : <sip: s-cscf -a . example . com; lr>, <sip: p-cscf -a. example . com; lr> 

From: User A <sip:user aeexample . com>; tag=372183 

To: User B <sip:user bsexample . com> 

Call -ID: 3 981742 93@phone-a.example.com 

CSeq: 1 INVITE 

Contact: <sip:user a@phone-a. example . com> 

Content-Type: application/sdp 

Content-Length: 135 

v=0 

o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s = - 

c=IN IP4 10.0.0.1 
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Step I Protocol | Interface | From | To | Message 



t=o 

m=audio 2222 RTP/AVP 
a=sendrecv 



10.1 [SIP \ IIBCFA IS-CSCFA 1 100 Trying 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(Sphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



10.2 IDIAMETER [Gq; [IBCFA |SPDF AA |AAR 



IBCF A uses the IP address of the SDP as the Globally-Unique-Address (i.e. the local IP address and port of the 
termination in C-BGF A that is associated with the IP address and port of Phone A). It is assumed that this association is 
statically established in C-BGF A to facilitate SIP signalling between the different address domains. 
It should be noted that the out direction indicates when given by an IBCF the inbound direction towards the local core 
network (i.e. for this message from B to A). 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "ibcf -a. example . com; 14511D; 557" > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "ibcf-a.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit out 17 from any to 10.0.0.1 2222" ] 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 
] 

[ Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 10.0.0.1 2223" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = DISABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2222 } 



] 



V4 



] 

[ V4 



] 



Transport -Address = 
Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2223 } 

Transport -Address = 
Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 



} 

] 

[ Reservation-Priority = DEFAULT (0) ] 

[ Globally-Unique-Address = 

[ Framed- IP-Address = 10.0.0.1 ] 
[ Address-Realm = "example.com" ] 

] 

[ Authorization-Lifetime = 450 ] 
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Step 



Protocol 



Interface 



From 



To 



Message 



10.3 



H.248 



la 



SPDFAA 



l-BGFA 



Add terminations 



The terminations are by default created as Inactive. Hence, the LocalControl descriptor is omitted in this message. SPDF 
AA defines all IP termination fields except the Id field. The Interface field is set to if1 , which is at the peer core network 
side of l-BGF A, to define the direction at which the termination is to be created. 



MEGACO/3 [ibcf-a.example.com] :55555 
Transaction = 1 { 
Context = ${ 

Add = ip/l/ifl/$ { 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- $ - - 
C=IN IP4 $ 
b=AS:104 

Remote { 
v=0 

m=- 2222 - - 
C=IN IP4 10 .0 .0 .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/$ { 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- $ - - 
C=IN IP4 $ 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
} /* Transaction */ 



10.4 



H.248 



-BGFA 



SPDFAA 



[Reply (Add) 



MEGACO/3 [ibgf-a.example.com] : 55555 
Reply = 1 { 

Context = 1 { 

Add = ip/l/ifl/1. 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 5554 - - 
c = IN IP4 10 . . .3 
b=AS:104 

}, 

Remote { 
v=0 

m=- 2222 - - 
c = IN IP4 10 . . .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/l. 
Media { 

Stream = 1 
Local { 
v=0 

m=- 6666 - - 
c=IN IP4 10 .0 .1.1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 



{ 
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Step 



Protocol 



Interface 



From 



To 



Message 



} /* Context 
Reply */ 



V 



:m: 



10.5 



DIAMETER 



SPDFAA 



IBCFA 



AAA 



<AA-Answer> 



Diameter Header: 265, PXY > 

Session-Id = "ibcf-a.example.com; 14511D;557" 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-aa.example.com" } 
Origin-Realm = "example.com" } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
Binding- Information = 
{ Binding- Input -List = 

[ V4-Transport-Address = 

Framed- IP-Address = 10.0.0.1 } 

Port -Number = 2222 } 



] 



V4 



V4 



] 



V4 



V4 



Transport -Address = 
Framed- IP-Address = 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 
Port -Number = 2223 

Transport -Address = 
Framed- IP-Address - 
Port -Number = } 



0.0.0.0 } 



10.0.0.1 } 



Binding -Output -List 



Transport -Address = 
Framed- IP-Address = 
Port-Number = 6666 

Transport -Address = 
Framed- IP-Address = 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 
Port -Number = 6667 

Transport -Address = 
Framed- IP-Address = 
Port -Number = } 



} 



0.0.0.0 } 



10.0.1.1 } 

} 



0.0.0.0 } 



10.0.1.1 } 



0.0.0.0 } 



Authorization-Lifetime = 
Auth-Grace-Period = 10 ] 



450 ] 



10.6 



SIP 



IBCFA 



IBCFB 



INVITE B 



INVITE sip:user_b(aexample.com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 
Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 
Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 
Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 
Max-Forwards: 67 

Record- Route : <sip: ibcf -a. example . com; lr>, <sip: s-cscf -a. example . com; lr>,<sip:p-cscf- 
a . example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_a@phone- a. example . com> 

Content-Type: application/sdp 

Content -Length: 135 

v=0 

o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s = - 

c=IN IP4 10.0.1.1 

t = 

m=audio 6666 RTP/AVP 

a=sendrecv 
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Step I Protocol | Interface | From | To | Message 



10.7 |SIP \ IIBCFB IIBCFA 1 100 Trying 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



10.8 IDIAMETER [Gq; |IBCFB |SPDF BB |AAR 



IBCF B uses the IP address of the signalling destination as the Globally-Unique-Address (i.e. the IP address and port of 
the IP address and port of G-BGF B that is associated with the IP address and port of Phone B). It is assumed that this 
association is statically established in C-BGF B to facilitate SIP signalling between the different address domains. 
It should be noted that the "in" direction indicates when given by an IBCF the inbound direction towards the peer core 
network (i.e. for this message from B to A). 

The Flow-Description is given from any to any based on the decision that it is to provide addresses for the local core 
network and not the link between the two core networks. This decision follows the same logic as used for the access 
where the Flow-Description provides addresses for the access network domain only. 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "ibcf -b. example . com; 25536F; 231" > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "ibcf-b.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit in 17 from any to any" 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 



] 



[ Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit in 17 from any to any" 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = DISABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding-Input-List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 



] 



V4 



Transport -Address = 
Framed- IP-Address = 10.0.1.1 } 
Port -Number = 6666 } 

Transport -Address = 
Framed- IP-Address = 0.0.0.0 } 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 10.0.1.1 } 
Port -Number = 6667 } 



] 



} 

] 

[ Reservation- Priority = DEFAULT (0) ] 

[ Globally-Unique-Address = 

[ Framed- IP-Address = 10.0.0.2 ] 
[ Address-Realm = "example.com" ] 

] 

[ Authorization-Lifetime = 450 ] 
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Step I Protocol | Interface | From | To | Message 



10.9 H.248 la SPDF BB l-BGF B Add terminations 



MEGACO/3 [ibcf-b.example.com] :55555 
Transaction = 1 { 
Context = $ { 

Add = ip/l/ifl/$ { 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- $ - - 
c=IN IP4 $ 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/$ { 
Media { 

Stream = 1 { 
Remote { 
v=0 

m=- 6666 - - 
c=IN IP4 10 .0 .1.1 
b=AS:104 

Local { 
v=0 

m=- $ - - 
c=IN IP4 $ 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
} /* Transaction */ 



10.10 IH.248 [la |I-BGF B |SPDF BB [Reply (Add) 



MEGACO/3 [ibgf-b.example.com] : 55555 
Reply = 1 { 

Context = 1 { 

Add = ip/l/ifl/1 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 7776 - - 
C=IN IP4 10 . .0 .5 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
Add = ip/l/if2/l 
Media { 

Stream = 1 { 
Local { 
v=0 

m=- 8888 - - 
C=IN IP4 10 . .1.2 
b=AS:104 

Remote { 
v=0 

m=audio 6666 RTP/AVP 
C=IN IP4 10 .0 .1.1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Add */ 
} /* Context */ 
} /* Reply */ 
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Step 



Protocol 



Interface 



From 



To 



Message 



10.11 



DIAMETER 



Gq' 



SPDFBB 



IBCFB 



AAA 



<AA-Answer> 



Diameter Header: 2 65, PXY > 

Session-Id = "ibcf -b. example . com; 25536F; 231" 
Auth-Application-Id = 16777222 (Gq) } 
Origin-Host = "spdf-bb.example.com" } 
Origin-Realm = "example.com" } 
Result-Code = DIAMETER_SUCCESS (2001) ] 
Binding-Information = 
{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 0.0.0.0 } 

Port -Number = } 



] 



V4 



V4 



] 



V4 



V4 



Transport -Address = 
Framed- IP-Address = 
Port -Number = 6666 

Transport -Address = 
Framed- IP-Address = 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 
Port-Number = 6667 



Binding-Output-List = 

[ V4-Transport-Address - 
Framed- IP-Address 
Port -Number = } 



Transport -Address = 
Framed- IP-Address = 
Port -Number = 7776 

Transport -Address = 
Framed- IP-Address = 
Port -Number = } 

Transport -Address = 
Framed- IP-Address = 
Port -Number = 7777 



10.0.1.1 } 
} 



0.0.0.0 } 



10.0.1.1 



0.0.0.0 } 



10.0.0.5 } 



0.0.0.0 } 



10.0.0.5 } 
} 



Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 



10.12 



SIP 



IBCFB 



S-CSCF B 



INVITE B 



INVITE sip:user_b(aexample.com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -b . example . com: 5060 ;branch=z9hG4bKH23gzx 
Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 
Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 
Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 
Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 
Max-Forwards: 66 

Record- Route : <sip: ibcf -b . example .com; lr>, <sip: ibcf -a. example . com; lr>,<sip:s-cscf- 
a. example . com; lr>, <sip: p-cscf -a. example .com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_a@phone- a. example . com> 

Content-Type: application/sdp 

Content -Length: 125 

v=0 

o=user_a 2890844526 2890842807 IN IP4 phone-a.example.com 

s = - 

c=IN IP4 10.0.0.5 

t = 

m=audio 7776 RTP/AVP 

a=sendrecv 
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Step 



Protocol 



Interface 



From 



To 



Message 



10.13 



SIP 



S-CSCF B 



IBCFB 



100 Trying 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP ibcf-b . example . com: 5060 ;branch=z9hG4bKH23gzx 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Content -Length: 



The above message finishes the first addition to the basic call setup signaling flow. Below follows the second addition to 
that signaling flow. 



31.0 [SIP \ IS-CSCFB IIBCFB | 200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ibcf -b . example . com: 5060 ;branch=z9hG4bKH23gzx 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 68 

Record- Route : <sip:p-cscf-b. example . com; lr>, <sip: s-cscf -b. example . com; lr>, <sip: ibcf - 
.example . com; lr>, <sip: ibcf -a. example . com; lr>, <sip: s-cscf -a. example . com; lr>,<sip:p-cscf- 
. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_b@phone-b. example . com> 

Content-Type: application/sdp 

Content -Length: 126 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s=- 

c=IN IP4 10.0.0.2 

t = 

m=audio 1110 RTP/AVP 

a=sendrecv 



31.1 IDIAIVIETER [Gq; [IBCFB [SPDF BB [AAR (Modify) 



IBCF B uses the IP address of the signalling destination as the Globally-Unique-Address (i.e. the IP address and port of 

the IP address and port of C-BGF B that is associated with the IP address and port of Phone B). 

It should be noted that the "in" direction indicates when given by an IBCF the inbound direction towards the peer core 

network (i.e. for this message from B to A) and out direction indicates when given by an IBCF the inbound direction 

towards the local core network (i.e. for this message from A to B). 

This message contains addresses and ports for both directions in the Binding-Input-List to allow these addresses and 

ports to be uniquely related to the directions given in the Flow-Descriptions (i.e. although the termination for the "in" 

direction is already established). That is, the direction given by the first Flow-Description refers to the first 

V4-Transport-Address in the Binding-Input-List, the second Flow-Description gives the direction of the second 

V4-Transport-Address in the Binding-Input-List, and so on. 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "ibcf -b. example . com; 25536F; 231" > 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "ibcf-b.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 

[ Flow-Description = "permit out 17 from any to 10.0.0.2 1110" ] 
[ Flow-Usage = NO_INFORMATION (0) ] 
[ Max-Requested-Bandwidth-DL = 96000 ] 
] 

[ Media-Sub-Component = 
{ Flow-Number = 2 } 

[ Flow-Description = "permit out 17 from any to 10.0.0.2 1111" ] 
[ Flow-Usage = RTCP (1) ] 
[ Max-Requested-Bandwidth-DL = 8000 ] 
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Step I Protocol | Interface | From | To | Message 



] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-StatUE? = ENABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1110 } 



] 

[ V4 



] 

[ V4 



] 

[ V4 



Transport -Address = 
Framed- IP-Address = 10.0.1.1 } 
Port -Number = 6666 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1111 } 



-Transport -Address = 

Framed- IP-Address = 10.0.1.1 } 
Port-Number = 6667 } 
] 
} 
] 

[ Reservation-Priority = DEFAULT (0) ] 
[ Globally-Unique-Address = 

[ Framed- IP-Address = 10.0.0.2 ] 
[ Address-Realm = "example.com" ] 
] 
[ Authorization-Lifetime = 450 ] 



31.2 IH.248 [la |SPDF BB |I-BGFB | Modify terminations 



SPDF BB (i.e. since it is a state full MGC) knows that the termination for the "in" direction is already established and 
therefore issues an add message for the "out" direction only. 



MEGACO/3 [ibcf-b.example.com] :55555 
Transaction = 2 { 
Context = l{ 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 7776 - - 
c=IN IP4 10.0.0.5 
b=AS:104 

}, 

Remote { 
v=0 

m=- 1110 - - 
c = IN IP4 10 .0 .0 .2 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 8888 - - 
C=IN IP4 10 .0 .1.2 
b=AS:104 

}, 

Remote { 
v=0 
m=- 6666 - - 
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Step 



Protocol 



Interface 



From 



To 



Message 



C=IN IP4 10 .0 .1.1 
b=AS:104 



} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Transaction */ 



31.3 



H.248 



l-BGFB 



SPDFBB 



[Reply (Modify) 



MEGACO/3 [ibgf-b.example.com] : 55555 
Reply = 2 { 

Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

Local { 
v=0 

m=- 7776 - - 
c=IN IP4 10 .0 .0 .5 
b=AS:104 

Remote { 
v=0 

m=- 1110 - - 
c = IN IP4 10 . . .2 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 8888 - - 
c=IN IP4 10 .0 .1.2 
b=AS:104 

}, 

Remote { 
v=0 

m=- 6666 - - 
c=IN IP4 10 .0 .1.1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Reply */ 



:m: 



31.4 



DIAMETER 



SPDFBB 



IBCFB 



AAA 



Since SPDF BB provided Binding-lnput-Lists for all addresses and ports in both directions the AAA will include this 
complete set of addresses and ports in the Binding-Information AVP as well. 



<AA-Answer> ::= < Diameter Header: 265, PXY > 

< Session-Id = "ibcf -b. example . com; 25536F; 231" 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "spdf-bb.example.com" } 

{ Origin-Realm = "example.com" } 

[ Result-Code = DIAMETER_SUCCESS (2001) ] 

[ Binding-Information = 

{ Binding- Input -List = 

[ V4 -Transport -Address = 

{ Framed- IP-Address = 10.0.0.2 } 
{ Port -Number = 1110 } 
] 
[ V4 -Transport -Address = 
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Step 



Protocol 



Interface 



From 



To 



Message 



V4 



] 



V4 



V4 



Framed- IP-Address = 
Port -Number = SSSS 



10.0.1.1 } 



Transport -Address = 
Framed- IP-Address = 10.0.0.2 } 
Port -Number = 1111 } 



Transport -Address = 
Framed- IP-Address = 
Port -Number = 6667 



Binding-Output-List = 

[ V4 -Transport -Address = 
Framed- IP-Address 
Port -Number = 8888 



10.0.1.1 } 



10.0.1.2 } 



} 



Transport -Address = 
Framed- IP-Address = 10.0.0.5 } 
Port -Number = 7776 } 



Transport -Address = 
Framed- IP-Address = 
Port -Number = 8889 



10.0.1.2 } 



Transport -Address = 
Framed- IP-Address = 10.0.0.5 
Port -Number = 7777 } 



Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 



31.5 



SIP 



IBCFB 



IBCFA 



|200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2. 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 67 

Record- Route : <sip : p-cscf -b . example . com; lr>, <sip: s-cscf -b . example . com; lr>, <sip: ibcf - 
.example .com; lr>, <sip: ibcf -a. example . com; lr>, <sip: s-cscf -a. example . com; lr>,<sip:p-cscf- 
. example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip :user_b(aphone-b . example . com> 

Content-Type: application/sdp 

Content -Length: 12 6 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s = - 

c=IN IP4 10.0.1.2 

t = 

m=audio 8888 RTP/AVP 

a=sendrecv 



31.6 



DIAMETER 



iGq' 



IBCFA 



SPDFAA 



|AAR (Modify) 



It should be noted that the "in" direction indicates when given by an IBCF the inbound direction towards the peer core 
networl< (i.e. for this message from A to B) and "out" direction indicates when given by an IBCF the inbound direction 
towards the local core network (i.e. for this message from B to A). 



<AA-Request> ::=< Diameter Header: 265, REQ, PXY > 

< Session-Id = "ibcf -a. example . com; 14511D; 557" 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "ibcf-a.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

[ Media-Component-Description = 

{ Media-Component -Number = 1 } 
[ Media-Sub-Component = 
{ Flow-Number = 1 } 
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Step I Protocol | Interface | From | To | Message 



[ Flow-Description = "permit in 17 from any to any" ] 

[ Flow-Usage = NO_INFORMATION (0) ] 

[ Max-Requested-Bandwidth-DL = 96000 ] 
] 
[ Media-Sub-Component = 

{ Flow-Number = 2 } 

[ Flow-Description = "permit in 17 from any to any" ] 

[ Flow-Usage = RTCP (1) ] 

[ Max-Requested-Bandwidth-DL = 8000 ] 
] 

[ AF-Application-Identif ier = "GQPRIME_SAMPLE_APP"] 
[ Media-Type = AUDIO (0) ] 
[ Flow-Status = ENABLED ] 
[ Reservation-Priority = DEFAULT (0) ] 
] 
[ Binding-Information = 

{ Binding-Input-List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2222 } 



] 

[ V4 



] 

[ V4 



] 

[ V4 



Transport -Address = 
Framed- IP-Address = 10.0.1.2 } 
Port -Number = 8888 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2223 } 



-Transport -Address = 

Framed- IP-Address = 10.0.1.2 } 
Port -Number = 8887 } 
] 
} 
] 

[ Reservation-Priority = DEFAULT (0) ] 
[ Globally-Unique-Address = 

[ Framed- IP-Address = 10.0.0.1 ] 
[ Address-Realm = "example.com" ] 
] 
[ Authorization-Lifetime = 450 ] 



31.7 IH.248 [la [SPPFAA |I-BGFA | Modify terminations 



SPDF AA (i.e. since it is a state full MGC) knows that the termination for the "out" direction is already established and 
therefore issues an add message for the "in" direction only. 



MEGACO/3 [ibcf-b.example.com] : 55555 
Transaction = 2 { 
Context = l{ 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

Local { 
v=0 

m=- 5554 - - 
c=IN IP4 10 . . .3 
b=AS:104 

}, 

Remote { 
v=0 

m=- 2222 - - 
c=IN IP4 10 . . .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

L 
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Step I Protocol | Interface | From | To | Message 



Local { 
v=0 

m=- 6666 - - 
C=IN IP4 10 .0 .1.1 
b=AS:104 

}, 
Remote { 

v=0 

m=- 8888 - - 

C=IN IP4 10 . .1.2 

b=AS:104 



} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Transaction */ 



31.8 IH.248 [la |I-BGFA |SPDF AA [Reply (Modify) 



MEGACO/3 [ibgf-b.example.com] : 55555 
Reply = 2 { 

Context = 1 { 

Modify = ip/l/ifl/1 { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 5554 - - 
c = IN IP4 10 .0 .0 .3 
b=AS:104 

}, 

Remote { 
v=0 

m=- 2222 - - 
c=IN IP4 10 .0 .0 .1 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
Modify = ip/l/if2/l { 
Media { 

Stream = 1 { 

LocalControl { 
Mode=SendRecv 

}, 

Local { 
v=0 

m=- 6666 - - 
c=IN IP4 10 .0 .1.1 
b=AS:104 

}, 

Remote { 
v=0 

m=- 8888 - - 
c=IN IP4 10 .0 .1.2 
b=AS:104 

} 
} /* Stream */ 
} /* Media */ 
} /* Modify */ 
} /* Context */ 
} /* Reply */ 



31.9 [DIAMETER [Gq; [SPDFAA [IBCFA [AAA 



<AA-Answer> ::= < Diameter Header: 265, PXY > 

< Session-Id = "ibcf -a. example . com; 14511D; 557" 

{ Auth-Application-Id = 16777222 (Gq) } 

{ Origin-Host = "spdf-aa.example.com" } 

{ Origin-Realm = "example.com" } 

[ Result-Code = DIAMETER_SUCCESS (2001) ] 

[ Binding-Information = 
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Step 



Protocol 



Interface 



From 



To 



Message 



Binding-Input-List = 

[ V4 -Transport -Address = 

Framed- IP-Address = 10.0.0.1 } 
Port -Number = 2222 } 



] 



V4 



V4 



] 



V4 



V4 



Transport -Address = 
Framed- IP-Address = 
Port -Number = 8888 

Transport -Address = 
Framed- IP-Address = 
Port -Number = 2223 



10.0.1.2 } 



10.0.0.1 } 



Transport -Address = 
Framed- IP-Address = 10.0.1.2 } 
Port -Number = 8889 } 



Binding -Output -List 



Transport -Address = 
Framed- IP-Address = 10.0.1.1 } 
Port -Number = 6666 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.3 } 
Port -Number = 5554 } 

Transport -Address = 
Framed- IP-Address = 10.0.1.1 } 
Port-Number = 6667 } 

Transport -Address = 
Framed- IP-Address = 10.0.0.3 } 
Port -Number = 5555 } 



Authorization-Lifetime = 450 ] 
Auth-Grace-Period = 10 ] 



31.10 



SIP 



IBCFA 



S-CSCF A 



|200 OK (SDP) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 66 

Record- Route : <sip:p-cscf-b. example . com; lr>, <sip: s-cscf -b. example . com; lr>, <sip: ibcf - 
b. example . com; lr>, <sip: ibcf -a. example . com; lr>, <sip: s-cscf -a. example . com; lr>,<sip:p-cscf- 
a . example . com; lr> 

From: User A <sip:user_a(aexample . com>; tag=372183 

To: User B <sip :user_b(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 INVITE 

Contact : <sip:user_b(aphone-b. example . com> 

Content-Type: application/sdp 

Content -Length: 12 6 

v=0 

o=user_b 29381748101 2948193018 IN IP4 phone-b.example.com 

s = - 

c=IN IP4 10.0.0.3 

t = 

m=audio 5554 RTP/AVP 

a=sendrecv 



The above message finishes the second addition to the basic call setup signaling flow. Below follows the third addition to 
that signaling flow. 



41.0 



SIP 



S-CSCF A 



IBCFA 



ACK 



ACK sip:user_b(aexample . com SIP/2.0 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 68 

From: User A <sip:user_a(aexample . com>; tag=372183 
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Protocol 



Interface 



From 



To 



Message 



To: User B <sip :user_beexaniple . com> 
Call -ID: 3 981742 93@phone-a.example.com 
CSeq: 2 ACK 

Contact : <sip:user_a@phone- a. example . com> 
Content -Length: 



41.2 



SIP 



IBCFA 



IBCFB 



ACK 



ACK sip:user_b@example . com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2. 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 060 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 67 

From: User A <sip:user_a(Sexample . com>; tag=372183 

To: User B <sip :user_b(Sexample . com> 

Call -ID: 3 981742 93@phone-a.example.com 

CSeq: 2 ACK 

Contact : <sip:user_a@phone- a. example . com> 

Content -Length: 



41.3 



SIP 



IBCFB 



S-CSCF B 



ACK 



ACK sip:user_b@example . com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -b . example . com: 5060 ;branch=z9hG4bKH23gzx 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z9hG4bKhf j 55z 

Via: SIP/2 . 0/UDP s-cscf -a . example . com: 5060 ;branch=z9hG4bKpm51mx 

Via: SIP/2 . 0/UDP p-cscf -a . example . com: 5 06 ;branch=z9hG4bKvp2yml 

Via: SIP/2. 0/UDP phone-a . example . com: 5060 ;branch=z9hG4bK74b03 

Max-Forwards: 66 

From: User A <sip:user_a@example . com>; tag=372183 

To: User B <sip :user_b@example . com> 

Call -ID: 3 981742 93@phone-a.example.com 

CSeq: 4 UPDATE 

Contact : <sip:user_a@phone- a. example . com> 

Content -Length: 



6.2.2 Session termination 



S-CSCF A 



IBCFA 



SPDFAA 



l-BGFA 



l-BC3^B 



SPDFBB 



IBCFB 



S-CSCF B 




Figure 6.2.2.1 : IMS end-to-end signalling chart for IBCF - session teardown 
Table 6.2.2.1 : IMS end-to-end messages for IBCF - session teardown 



Step 


Protocol 


Interface 


From 


To 


Message 


51.0 


SIP 




S-CSCF B 


IBCFB 


BYE 


BYE sip:user a@example.com SIP/2.0 

Via: SIP/2. 0/UDP s-cscf -b . example . com: 5060 ;branch=fg7gjH13ss8r 
Via: SIP/2. 0/UDP p-cscf -b . example . com: 5060 ;branch=z9hG4bKslppO 
Via: SIP/2 . 0/UDP phone -b . example . com: 5 06 ;branch=z9hG4bKjwafcb9 
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Step 



Protocol 



Interface 



From 



To 



Message 



Max-Forwards: 68 

Route : <sip: ibcf-b . example . com; lr>, <sip: ibcf- a. example . com; lr>, <sip: s-cscf- a. example . com; lr>, 

<sip:p-cscf -a. example . com; Ir 

From: User B <sip:user_b(aexample . com>; tag=4fxdcel21s 

To: User A <sip :user_a(aexample . com> 

Call -ID: 3 981742 93(aphone-a. example, com 

CSeq: 1 BYE 

Content -Length: 



51.1 



DIAMETER 



iGq- 



IBCFB 



SPDFBB 



STR 



<ST-Request> ::=< Diameter Header: 275, REQ, PXY > 

< Session-Id = "ibcf -b. example . com; 25536F; 231" 

{ Origin-Host = "ibcf-b.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 



51.2 



H.248 



la 



SPDFBB 



l-BGFB 



Subtract termination BB 



MEGACO/3 [ibcf-b.example.com] : 55555 
Transaction = 3 { 



Context = 1 { 

Subtract 

Subtract 

} /* Context 

/* Transaction 



ip/l/ifl/1 {Audit{Statistics} } 
ip/l/if2/l {Auditjstatistics} } 



51.3 



H.248 



la 



l-BGFB 



SPDFBB 



[Reply 



MEGACO/3 [ibgf-b.example.com]: 
Reply = 3 { 

Context = 1 { 

Subtract = ip/l/ifl/1 
Statistics { 

nt/dur=450000, 
nt/os=5400000, 
nt/or=5400000, 
gm/dp=0 
} 
} 

Subtract = ip/l/if2/l 
Statistics { 

nt/dur=450000, 
nt/os=450000, 
nt/or=450000, 
gm/dp=0 

} 
} /* Subtract */ 
} /* Context */ 
} /* Reply */ 



in milliseconds 

Octets Sent 

Octets Received 

number of packets discarded 



in milliseconds 

Octets Sent 

Octets Received 

number of packets discarded 



51.4 



DIAMETER 



iGq' 



SPDFBB 



IBCFB 



STA 



<ST-Answer> ::= < Diameter Header: 275, PXY > 

< Session-Id = "ibcf -b. example . com; 25536F; 231" 

{ Origin-Host = "spdf-bb.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 

[ Result-Code = DIAMETER SUCCESS (2001) ] 



51.5 



SIP 



IBCFB 



IBCF A 



BYE 



BYE sip:user_a@example . com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -b . example . com: 5060 ;branch=z91iG4bKH23gzx 

Via: SIP/2. 0/UDP s-cscf -b . example . com: 5060 ;branch=fg7gjH13ss8r 

Via: SIP/2. 0/UDP p-cscf-b . example . com: 5060 ;branch=z91iG4bKslppO 

Via: SIP/2 . 0/UDP plione-b . example . com: 5060 ;brancli=z91iG4bKjwafcb9 

Max-Forwards: 67 

Route : <sip: ibcf -a . example . com; lr>, <sip: s-cscf -a. example . com; lr>. 

From: User B <sip:user_b(aexample . com>; tag=4fxdcel21s 

To: User A <sip :user_a(aexample . com> 

Call -ID: 3 981742 93(aplione-a. example, com 

CSeq: 1 BYE 

Content -Lengtli: 



<sip:p-cscf -a. example . com; Ir 
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Step 



Protocol 



Interface 



From 



To 



Message 



51.6 



DIAMETER 



iGq' 



IBCFA 



SPDFAA 



STR 



<ST-Request> ::=< Diameter Header: 275, REQ, PXY > 

< Session-Id = "ibcf -a. example . com; 14511D; 557" 

{ Origin-Host = "ibcf-a.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Auth-Application-Id = 16777222 (Gq) } 



51.7 



H.248 



la 



SPDFAA 



l-BGFA 



Subtract termination AA 



MEGACO/3 [ibcf-a.example.com] : 55555 
Transaction = 3 { 
Context = 1 { 

Subtract = ip/l/ifl/1 {Audit {Statistics} } 
Subtract = ip/l/if2/l {Audit {Statistics} } 
} /* Context */ 
} /* Transaction */ 



51.8 



H.248 



l-BGFA 



SPDFAA 



[Reply 



MEGACO/3 [ibgf-a.example.com]: 
Reply = 3 { 

Context = 1 { 

Subtract = ip/l/ifl/1 
Statistics { 

nt/dur=450000, 
nt/os=5400000, 
nt/or=5400000, 
gm/dp=0 
} 
} 

Subtract = ip/l/if2/l 
Statistics { 

nt/dur=450000, 
nt/os=450000, 
nt/or=450000, 
gm/dp=0 

} 
} /* Subtract */ 
} /* Context */ 
} /* Reply */ 



in milliseconds 

Octets Sent 

Octets Received 

number of packets discarded 



in milliseconds 

Octets Sent 

Octets Received 

number of packets discarded 



51.9 



DIAMETER 



IGq' 



SPDFAA 



IBCFA 



STA 



<ST-Answer> ::= < Diameter Header: 275, PXY > 

< Session-Id = "ibcf -a. example . com; 14511D; 557" 

{ Origin-Host = "spdf-aa.example.com" } 

{ Origin-Realm = "example.com" } 

{ Destination-Realm = "example.com" } 

{ Autli-Application-Id = 16777222 (Gq) } 

[ Result-Code = DIAMETER SUCCESS (2001) ] 



51.10 



SIP 



IBCFA 



S-CSCFA 



BYE 



BYE sip:user_a(aexample . com SIP/2.0 

Via: SIP/2. 0/UDP ibcf -a . example . com: 5060 ;branch=z91iG4bKlif j 55z 

Via: SIP/2. 0/UDP ibcf -b . example . com: 5060 ;branch=z91iG4bKH23gzx 

Via: SIP/2. 0/UDP s-cscf-b . example . com: 5060 ;brancli=fg7gjH13ss8r 

Via: SIP/2. 0/UDP p-cscf-b . example . com: 5060 ;brancli=z91iG4bKslppO 

Via: SIP/2 . 0/UDP plione-b . example . com: 5 06 ;brancli=z91iG4bKjwafcb9 

Max-Forwards: 66 

Route : <sip: s-cscf- a. example . com; lr>, <sip:p-cscf -a. example . com; Ir 

From: User B <sip:user_b(aexample . com>; tag=4fxdcel21s 

To: User A <sip :user_a(aexample . com> 

Call -ID: 3 981742 93@phone-a.example.com 

CSeq: 1 BYE 

Content -Lengtli: 
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Annex A (informative): 
Bibliography 

• IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS)". 
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